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The Reliable Multicast Protocol Specification 
Protocol Operation 

RMP Library Version: 1.3b (1.3 Beta) 

This appendix contains the complete state tables for RMP Normal 
Operation, Multi— RPC Extensions, Membership Change Extensions, and 
Reformation Extensions. First the event types are presented. 
Afterwards, each RMP operation state, normal and extended is 
presented individually and its events shown. 


Events in the RMP specification are one of several things. (1) 
Arriving packets, (2) Expired alarms, (3) User events, (4) 
Exceptional conditions. The specification event types are: 


Event Type 

Description 


Data 

Data Packet 


ACK 

ACK Packet 


nack 

NACK Packet 


Conf 

Confirm Packet 


NMD 

Non-Member Data Packet 


nma 

Non-Member ACK Packet 


NL 

New List Packet 


LCR 

List Change Request Packet 

RecStart 

Recovery Start Packet 


RecVote 

Recovery Vote Packet 


RecACKNL 

Recovery ACK New List 

Packet 

RecAbort 

Recovery Abort Packet 


Failure 

Retransmission timeout 

on packet 

TPA 

Token Pass Alarm 


CTPA 

Confirm Token Pass Alarm 

RTA 

Random Timeout Alarm 


MandLv 

Mandatory Leave Alarm 


CommitNL 

Commit New List Notification 

JoinReq 

Application request to 

join group 


Packet Positive Acknowledgements and Fault Detection 

Some packets are retransmitted on a scheduled basis until a given set 
of condition occur that cease that retransmit schedule. This set of 
conditions can be considered as a positive acknowledgement for the 


Whetten, Montgomery, Callahan RMP 1.3b 


[Page 1] 


RMP Operation 


Reliable Multicast Protocol 


5 October 1995 


packet. The different RMP packets and the positive acknowledgement 
conditions for each are shown in the table below. The packets with 
(none) as their positive acknowledgement conditions are only sent 
once and are not scheduled for any kind of retransmission. 


Packet Type 
Data 

ACK 


NACK 

Confirm 

Non-Member Data (NMD) 

Non-Member ACK (NMA) 
New List (NL) 


List Change Request (LCR) 

Recovery Start 

Recovery Vote 

Recovery ACK New List 
Recovery Abort 


Positive Acknowledgment Conditions 
Reception of ACK Packet that contains 
packet 

Reception of ACK, New List, or Confirm 
packet with Timestamp >= Timestamp of 
packet 

Reception of requested Packet (s) 

(none) 

Reception of Non-Member ACK Packet that 

contains packet 

(none) 

Reception of ACK, New List, or Confirm 
packet with Timestamp >= Timestamp of 
packet 

Reception of a New List Packet 
containing response to request 
Creation of a valid New List Packet or 
X retransmits 

Reception of a New List Packet from 
Reform Site 

Reception of Null ACK from Reform Site 
(none) 


If a set number of retransmissions, call this value X, for a packet 
occur without the positive acknowledgement conditions being met, then 
a Failure event is generated for that packet . This event is indica- 
tive of a failure (or blockage) being detected within the protocol 
operation (the cause of which being an application failure, a site 
failure, or a communication failure) . Failures in RMP are assumed to 
be failures that are non-corrupt ive . All members are assumed to be 
well behaved in the presence of failures and not miscreant . 


Duplicate Detection and Filtering of Packets 


Packets must pass through two devices before they are allowed to be 
processed. The first level is filtering. This level examines the 
packet type and TRID. If the TRID is not a valid TRID, then the 
packet is dropped. The state of the site is also taken into account. 
When the site is in the Not In Ring state or the Joining Ring state, 
it does not have information about the current TRID of the group. 

Thus filteirng must be down based on packet type and packet contents. 
For example, as specified below, a site in the Joining Ring state 
transitions into the Token Site state upon a New List packet . To 
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filter out possible errant transitions, the filter must drop all 
other New List packets not meeting the transition criteria. 

The second device is duplicate detection. Duplicates are assumed to 
be dropped and not processed. Duplicates can be detected based on the 
packet type and state of the site. For packets with explicit times- 
tamps, ACKs and NLs, the timestamp can be used to determine if the 
packet is a duplicate. For implicit timestamped packets. Data, NMD, 
and LCRs, the job is slightly more complicated. Careful track of 
sequence numbers from clients as well as group members must be kept 
for duplicates to be detected. NMAs, NACKs and Confirm packets are 
never checked for being duplicates. During reformation, duplicates 
are allowed to be processed (as long as they are part of reformation. 
Data, NMD, ACK, NL, and LCR packets are still put through duplicate 
detection) . Another exception to the duplicate detection rule is when 
the site is in the Token Site state. Duplicate detection is not done 
on any ACK or NL packets that arrive when the site is in the Token 
Site state. 

Algorithms and Data Structures 

Two data structures are used by RMP. The first is the DataQ. This is 
a FIFO structure that holds Data, NMD, and LCR packets as they 
arrive. The second structure is an Ordered FIFO called an OrderingQ. 
This FIFO is ordered based on timestamps. Each member of the FIFO, 
called a slot, is assigned a unique timestamp. In this way, the FIFO 
has elements which are monotonically increasing. Each slot of the 
OrderingQ is one of the following types of packets: Data, NMD, ACK, 
or NL. ACK and NL packets contain explicit timestamps to order them 
in the OrderingQ. Data, NMD, and LCR packets are given implicit 
timestamps by the corresponding ACK or NL that addresses them. There- 
fore, an ACK with timestamp of 5 which acknowledges 3 packets will 
implicitly give 3 Data or NMD packets implicit timestamps of 6, 7, 
and 8. LCR packets are dropped once a corresponding NL is received. 
LCRs are never put into the OrderingQ. 

In the state tables given below, it is assumed that the addition of 
an ACK into the OrderingQ also enqueues empty slots for each packet 
acknowledged by the ACK. Each slot in the OrderingQ is assigned a 
state. There are four possible states for each slot. They are: (1) 
Packet Missing, (2) Packet Requested, (3) Packet Received, and (4) 
Packet Delivered. A slot usually starts out as being in the Packet 
Missing state. Once a NACK is sent for that packet, the state changes 
to Packet Requested. When the slot is filled by a packet, the state 
changes to Packet Received, and, finally, when the packet is 
delivered to the application the slot state is changed to Packet 
Delivered. 
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A few algorithms are provided to specify the operation of the Order- 
ingQ and DataQ during the protocol operation. The first algorithm is 
the Update-OrderingQ algorithm presented below. 

Update-OrderingQ () : 

for each (slot in the OrderingQ (starting with lowest timestamp)) 

If (slot timestamp not equal to last slot timestamp + 1) then 
EnQueue as many empty slots to cover missing timestamps 
for each (new slot to be Enqueued) Loop 
Send NACK for missing timestamp 
Mark slot state as Packet Requested 
End for. 

End If. 

If (slot state is Packet Missing) then 
Search DataQ for missing packet 

If (packet is found in DataQ) then 
Remove packet from DataQ 
Place packet in OrderingQ 
Mark slot as Packet Received 
Attempt-Packet-Delivery (slot) 

Update information about packet source 

Else 

Send NACK for packet 

Mark slot as Packet Requested 

End If. 

Else If (slot state is Packet Committed) then 

If (token has been passed enough times to satisfy QoS 
resiliency requirements) then 
Mark slot as Packet Delivered 

Notify application that QoS resiliency has been met 
Update information about packet source 
End If. 

Else If (slot state is Packet Requested) then 
Search DataQ for missing packet 

If (packet is found in DataQ) then 
Remove packet from DataQ 
Place packet in OrderingQ 
Mark slot as Packet Received 
Attempt-Packet-Delivery (slot ) 

Update information about packet source 

End If. 

Else If (slot state is Packet Received) then 
Attempt -Packet-Delivery (slot) 

Update information about packet source 
Else If (slot state is Packet Delivered) then 
Update information about packet source 

End If. 

End for. 
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while (the number of ACK Packets and New Lists Packets in OrderingQ 
is greater than the number of members of the Token Ring) Loop 
DeQueue lowest timestamp and discard packet 
End while. 

End Update-OrderingQ. 

As auxillarily algorithm, Attempt-Packet-Delivery, is used by 
Update-OrderingQ to determine if a packet is deliverable and to 
deliver the packet to the application. The Attemp-Packet-Delivery 
algorithm is presented below. 

Attempt -Packet-Delivery ( slot ): 

If (slot is a Data Packet or Non-Member Data Packet) then 
If (slot packet has QoS equal to Unordered) then 
Commit the packet to the application 
Mark slot as Packet Delivered 

Else If (slot packet has QoS equal to Source Ordered) then 
If (all of the smaller sequence numbers from that 
source have been delivered) then 

Commit the packet to the application 
Mark slot as Packet Delivered 
End If. 

Else If (slot packet has QoS equal to Totally Ordered) then 
If (all of the timestamps smaller than the slots 
timestamps have been delivered) then 
Commit the packet to the application 
Mark slot as Packet Delivered 
End If. 

Else If (slot packet has QoS equal to K Resilient or 

slot packet has QoS equal to Majority 
Resilient or slot packet has QoS equal 

to Totally Resilient) then 

If (all of the timestamps smaller than the slots 
timestamps have been delivered) then 
Commit the packet to the application 
Mark slot as Packet Committed 
End If. 

End If. 

Else If (slot is a New List Packet) 

If (all of the timestamps smaller than the slots timestamps have 
been delivered) then 

Commit the New List and notify application 
Mark slot as Packet Delivered 

End If. 

Else If (slot is an ACK Packet) then 
Mark slot as Packet Delivered 
End If. 

End Attempt-Packet-Delivery. 
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These two algorithms describe the behavior desired for packets to be 
ordered and delivered. The last algorithm presented is the Pass-Token 
algorithm. This algorithm describes how a Token Site is to fill pass 
the token through either a NL or an ACK. The algorithm is presented 
below. 

Pass-Token ( ) : 

for each (member of the DataQ) 

If (member is a List Change Request Packet and request can 
be granted and packet is eligible) then 

Generate a New List Packet for request 
Send New List Packet 
Exit Loop 

Else If (member is a Data Packet or a Non-Member Data Packet 
and is eligible to be acknowledged) then 
Generate ACK Packet containing as many Data Packets 
and Non-Member Data Packets as are eligible in the DataQ 
Send ACK Packet 
Exit Loop 

End If. 

End for. 

If (ACK Packet or New List Packet could not be generated) then 

Return to calling routine reporting Token Not Passed 

Else 

Return to calling routine reporting Token Passed 

End If. 

End Pass-Token. 

For an LCR, Data, or NMD packet to be eligible, the sequence number 
of the packet must have the expected next value for the source. No 
strict upper bound is placed onthe number of NMD or Data packets an 
ACK may contain, although differing implementations may impose their 
own limits. 

Delivery of low QoS packets is also checked as the packet arrives and 
placed into the DataQ. If conditions are such that the packet meets 
its QoS when it arrives, then the packet may be delivered as well as 
being placed into the DataQ. Thus when the Update-OrderingQ algorithm 
pulls the packet out of the DataQ, the slot into which it is placed 
is to be marked as Packet Delivered instead of Packet Received. This 
behavior is assumed in the state tables presented below. Another 
behavior assumed in the preceeding algorithms is that the implementa- 
tion will block packets with resilient QoSs from actual delivery to 
the application until the conditions meeting their QoS are met. This 
does mean blocking the delivery of other QoSs (Source and Totally 
Ordered) that depend on that higher QoS packet. 

State Tables and Actions 
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In the tables presented below each state is shown along with the 
actions and conditions required to transition into the next state. 
Assume that events not shown are ignored unless they are specifically 
discussed below. The different states of RMP operation are: 


TS 

Token Site State 

NTS 

Not Token Site State 

GP 

Getting Packets State 

PT 

Passing Token State 

JR 

Joining Ring State 

LR 

Leaving Ring State 

NIR 

Not In Ring State 

SR 

Start Recovery State 

CNL 

Created New List State 

SV 

Sent Vote State 

ACKNL 

ACK New List State 

AR 

Abort Recovery State 


In all states the following behaviors are necessary. All NACK events 
are handled the same way no matter what the current state is . The 
default action for NACK responses is to examine the OrderingQ and 
retransmit the requested timestamped packet (either explicit times- 
tamp or implicit timestamp) . NACK policy controls how these are sent, 
via multicast or unicast, and the timing factors involved. Another 
issue is generation of NMA packets in response to NMD packets . The 
default behavior is to have the site which generates the ACK contain- 
ing the NMD to generate an NMA for that NMD and unicast the NMA to 
the client. If after this is done, a member of the group sees a 
duplicate NMD (one that has already been acknowledged and ordered), 
then the member of the list generates an NMA and unicasts it to the 
client. The down side of this is that this may result in NMA implo- 
sion to the client. This policy may also be changed on an implementa- 
tion basis to be that the same site always sends the NMA. 

It is recommended that implementations differentiate, to the applica- 
tion, NMA packets that hold replies and NMA packets that do not hold 
replies. The default behavior for a client is to periodically send an 
NMD to the group (via unicast or multicast) until it receives an NMA 
(holding no reply) for that NMD, notify the application that the 
group has received the message, then wait for another NMA that holds 
a reply. If the reply is in the form of multiple NMA packets, then 
each should be delivered as they arrive. Missing NMA replies can be 
requested by sending another NMD (with an increased sequence number), 
thus causing another message to be delivered to the group. This can 
be done repeatedly until a client finally gets its reply. Alterna- 
tively, a client may mark the Multiple Copies flag of the NMD so that 
multiple copies of the same NMD will be delivered to the application 
as they arrive. 


Whetten, Montgomery, Callahan RMP 1.3b 


[Page 7] 


RMP Operation 


Reliable Multicast Protocol 


5 October 1995 


Due to the fact that this set of policies does not give any guaran- 
tees to the client that the desired QoS was met, the application is 
fully responsible for the response policy that it will use. For exam- 
ple, if clients built for an application need to know when the QoS is 
met for the NMD, then the group must send a NMA with a response when 
that QoS is met and the NMD delivered to the application. 
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Token Site State Table (current state is TS) . Events not mentioned 
have no action and cause no transition. The sequence of actions are 
executed before the conditions are checked. 




Next 



Event 

Condition (s) 

State 

Action (s) 


Data 

t 

Token Passed 

PT 

place packet in 
Pass-Token 

DataQ 

Data 

'.Token Passed 

TS 

place packet in 
Pass-Token 

DataQ 

NMD 

Token Passed 

PT 

place packet in 
Pass-Token 

DataQ 

NMD 

'.Token Passed 

TS 

place packet in 
Pass-Token 

DataQ 

LCR 

Token Passed 

PT 

place packet in 
Pass-Token 

DataQ 

LCR 

'.Token Passed 

TS 

place packet in 
Pass-Token 

DataQ 

ACK 

Named Token 

TS 

Unicast Confirm 

to 


Site 


Source 


NL 

Named Token 

TS 

Unicast Confirm 

to 


Site 


Source 


Failure 

(none) 

SR 

Multicast RecStart 

RecStart 

(none) 

SV 

Unicast RecVote 
Reform Site 

to 

TPA 

(none) 

PT 

Generate Null ACK 
Multicast Null ACK 

CTPA 

(none) 

TS 

Unicast Confirm 

to 


last Token Site 
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Passing Token State Table (current state is PT) . Events not mentioned 
have no action and cause no transition. The sequence of actions are 
executed before the conditions are checked. 


Event 

Condition (s) 

Next 

State 

Action (s) 

Data 

(none) 

PT 

place packet in DataQ 

NMD 

(none) 

PT 

Update-OrderingQ 
place packet in DataQ 

LCR 

(none) 

PT 

Update-OrderingQ 
place packet in DataQ 

NL 

(named Token Site 

NTS 

Update-OrderingQ 
Add NL to OrderingQ 

NL 

named Token Site 

PT 

Update-OrderingQ 
Add NL to OrderingQ 

NL 

Order ingQ consistent 
Token passed 
named Token Site 

TS 

Update-OrderingQ 

Pass-Token 

Add NL to OrderingQ 

NL 

OrderingQ consistent 
(Token passed 
named Token Site 

GP 

Update-OrderingQ 

Pass-Token 

Add NL to OrderingQ 

ACK 

(OrderingQ consistent 
(named Token Site 

NTS 

Update-OrderingQ 
Add ACK to OrderingQ 

ACK 

named Token Site 

PT 

Update-OrderingQ 
Add ACK to OrderingQ 

ACK 

OrderingQ consistent 
Token passed 
named Token Site 

TS 

Update-OrderingQ 

Pass-Token 

Add ACK to OrderingQ 

ACK 

OrderingQ consistent 
(Token passed 
named Token Site 

GP 

Update-OrderingQ 

Pass-Token 

Add ACK to OrderingQ 

Conf 

(OrderingQ consistent 
Timestamp >= 

NTS 

Update-OrderingQ 

Update-OrderingQ 

Failure 

Last token pass 

Timestamp 

(none) 

SR 

Multicast RecStart 

RecStart 

(none) 

SV 

Unicast RecVote to 




Reform Site 
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Not Token Site State Table (current state is NTS) . Events not men- 
tioned have no action and cause no transition. The sequence of 
actions are executed before the conditions are checked. 




Next 


Event 

Condition (s) 

State 

Action (s) 

Data 

(none) 

NTS 

place packet in DataQ 
Updat e-Order ingQ 

NMD 

(none) 

NTS 

place packet in DataQ 
Updat e-Order ingQ 

LCR 

(none) 

NTS 

place packet in DataQ 
Updat e-Order ingQ 

NL 

[named Token Site 

NTS 

Add NL to OrderingQ 
Updat e-Order ingQ 

NL 

named Token Site 
OrderingQ consistent 
Token passed 

PT 

Add NL to OrderingQ 
Updat e-Order ingQ 
Pass-Token 

NL 

named Token Site 
OrderingQ consistent 
[Token passed 

TS 

Add NL to OrderingQ 
Updat e-Order ingQ 
Pass-Token 

NL 

named Token Site 
[OrderingQ consistent 

GP 

Add NL to OrderingQ 
Updat e-Order ingQ 

ACK 

[named Token Site 

NTS 

Add ACK to OrderingQ 
Updat e-Order ingQ 

ACK 

named Token Site 
OrderingQ consistent 
Token passed 

PT 

Add ACK to OrderingQ 
Updat e-Order ingQ 
Pass-Token 

ACK 

named Token Site 
OrderingQ consistent 
[Token passed 

TS 

Add ACK to OrderingQ 

Update-OrderingQ 

Pass-Token 

ACK 

named Token Site 
[OrderingQ consistent 

GP 

Add ACK to OrderingQ 
Update-OrderingQ 

Failure 

(none) 

SR 

Multicast RecStart 

RecStart 

(none) 

SV 

Unicast RecVote to 
Reform Site 

CommitNL 

NL does not contain 
site 

LR 

Schedule MandLv 
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Getting Packets State Table (current state is GP) . Events not men- 
tioned have no action and cause no transition. The sequence of 
actions are executed before the conditions are checked. 




Next 


Event 

Condition (s) 

State 

Action (s) 

Data 

OrderingQ consistent 
Token passed 

PT 

place packet in DataQ 
Updat e-Order ingQ 
Pass-Token 

Data 

OrderingQ consistent 
! Token passed 

TS 

place packet in DataQ 
Updat e-Order ingQ 
Pass-Token 

Data 

'.OrderingQ consistent 

GP 

place packet in DataQ 
Updat e-Order ingQ 

NMD 

OrderingQ consistent 
Token passed 

PT 

place packet in DataQ 
Updat e-Order ingQ 
Pass-Token 

NMD 

OrderingQ consistent 
'.Token passed 

TS 

place packet in DataQ 
Updat e-Order ingQ 
Pass-Token 

NMD 

'.OrderingQ consistent 

GP 

place packet in DataQ 
Updat e-Order ingQ 

LCR 

(none) 

GP 

place packet in DataQ 
Update-Order ingQ 

ACK 

OrderingQ consistent 
Token passed 

PT 

Add ACK to OrderingQ 

Update-OrderingQ 

Pass-Token 

ACK 

OrderingQ consistent 
'Token passed 

TS 

Add ACK to OrderingQ 

Update-OrderingQ 

Pass-Token 

ACK 

[OrderingQ consistent 

GP 

Add ACK to OrderingQ 
Update-OrderingQ 

NL 

OrderingQ consistent 
Token passed 

PT 

Add NL to OrderingQ 

Update-OrderingQ 

Pass-Token 

NL 

OrderingQ consistent 
[Token passed 

TS 

Add NL to OrderingQ 

Update-OrderingQ 

Pass-Token 

NL 

[OrderingQ consistent 

GP 

Add NL to OrderingQ 
Update-OrderingQ 

Failure 

(none) 

SR 

Multicast RecStart 

RecStart 

(none) 

sv 

Unicast RecVote to 
Reform Site 
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Not In Ring State Table (current state is NIR) . Events not mentioned 
have no action and cause no transition. The sequence of actions are 
executed _before_ the conditions are checked. 

Next 

Event Condition (s) State Action (s) 

JoinReq (none) JR Multicast LCR to join ring 

NMA NMA holds reply NIR Deliver reply to application 

Joining Ring State Table (current state is JR) . Events not mentioned 
have no action and cause no transition. The sequence of actions are 
executed before the conditions are checked. 




Next 


Event 

Condition (s) 

State 

Action (s ) 

NL 

named Token Site 

TS 

Add NL to OrderingQ 
Updat e-Order ingQ 

Failure 

(none) 

TS 

Generate NL to form 
own Token Ring 


Leaving Ring State Table (current state is LR) . Events not mentioned 
have no action and cause no transition. The sequence of actions are 
executed before the conditions are checked. 


Event 

Condition (s) 


Next 

State 

Action (s) 

NL 

Exit condition 

met 

NIR 

(none) 

NL 

[Exit condition 

met 

LR 

(none) 

ACK 

Exit condition 

met 

NIR 

(none) 

ACK 

!Exit condition 

met 

LR 

(none) 

MandLv 

(none) 


NIR 

(none) 


NOTE: Exit condition is that a number of Token Passes has occurred in 
the group equal to the number of people in the group when the site 
transitioned into LR. 
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Start Recovery State Table (current state is SR) . Events not men- 
tioned have no action and cause no transition. The sequence of 
actions are executed before the conditions are checked. 


Event 

Condition (s) 

Next 

State 

Action (s) 

Data 

(none) 

SR 

place packet in DataQ 

NMD 

(none) 

SR 

Update-OrderingQ 
Update SynchTSP 
place packet in DataQ 

LCR 

(none) 

SR 

Update-OrderingQ 
Update SynchTSP 
place packet in DataQ 

ACK 

(none) 

SR 

Update-OrderingQ 
Add ACK to OrderingQ 

NL 

(none) 

SR 

Update-OrderingQ 

Update SynchTSP and MaxTSP 

Add NL to OrderingQ 

Failure 

packet is 

CNL 

Update-OrderingQ 

Update SynchTSP and MaxTSP 

Create New List 

Failure 

RecStart 
'.only site 
packet is 

NIR 

Multicast New List 
Create New List 

Failure 

RecStart 
only site 
List is invalid 
packet is 

TS 

Commit New List 
Create New List 

RecVote 

RecStart 
only site 
List is valid 
incorrect Info 

AR 

Commit New List 
Multicast New List 

Multicast RecAbort 

RecVote 

Vote MaxTSP > 

SR 

Update MaxTSP 

RecVote 

MaxTSP 

Vote MaxTSP <= 

SR 

Update source vote 

RecVote 

MaxTSP 

OrderingQ consistent 

CNL 

Create New List 

RecAbort 

Vote from each site 
Each Voter synched 
correct Info 

AR 

Multicast New List 
(none) 

RecStart 

incorrect Info 

AR 

Multicast RecAbort 


NOTE: incorrect Info means that the Token Ring Version, New Token 
Ring ID, or Reform Site information in the packet is incorrect. Any 
update to the value of MaxTSP or SynchTSP for the Reform Site prompts 
a restart of the RecStart packet. Each Voter is synched if the vote 
from that voter has its SynchTSP set to the MaxTSP of the current 
reformation. 
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Created New List State Table (current state is CNL) . Events not men- 
tioned have no action and cause no transition. The sequence of 
actions are executed before the conditions are checked. 




Next 


Event 

Condition (s) 

State 

Action (s) 

Data 

(none) 

CNL 

place packet in DataQ 
Updat e-Order ingQ 

NMD 

(none) 

CNL 

place packet in DataQ 
Updat e-Order ingQ 

LCR 

(none) 

CNL 

place packet in DataQ 
Updat e-OrderingQ 

RecACKNL 

incorrect Info 

AR 

Multicast RecAbort 

RecACKNL 

! All sites have ACKed 

CNL 

Mark source as ACKed 

RecACKNL 

All sites have ACKed 
List is valid 

PT 

Add NL to OrderingQ 
Commit NL 

Multicast Null ACK 

RecACKNL 

All sites have ACKed 
List is invalid 

NIR 

Add NL to OrderingQ 
Commit NL 

Failure 

packet is NL 
List is valid 

AR 

Multicast RecAbort 

Failure 

packet is NL 
List is invalid 

NIR 

Add NL to OrderingQ 
Commit NL 

RecAbort 

correct Info 

AR 

(none) 

RecStart 

incorrect Info 

AR 

Multicast RecAbort 

RecVote 

correct Info 

CNL 

Unicast Reformation 
NL to voting site 

NOTE: Reformation NL is generated 

in the SR 

state. This NL is not 


added to the OrderingQ or committed by the Reform Site until it is 
positive that all the Slave Sites have it. This is shown as having 
ACKs from all those involved in Reformation. Valid lists are lists 
that pass the Minimum Size Requirements as set forth by the members. 
Invalid lists fail to meet these requirements. 

ACK and NL packets that are not duplicates arriving in this state are 
to cause warnings. The ring should not be sending them because the 
synchronization point for the group has already been chosen and 
should not be changed. 
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Sent Vote State Table (current state is SV) . Events not mentioned 
have no action and cause no transition. The sequence of actions are 
executed before the conditions are checked. 


Event 

Condition (s) 

Next 

State 

Action (s) 

Data 

(none) 

SV 

place packet in DataQ 

NMD 

(none) 

SV 

Update-OrderingQ 
Update RecVote 
place packet in DataQ 

LCR 

(none) 

SV 

Update-OrderingQ 
Update RecVote 
place packet in DataQ 

ACK 

(none) 

SV 

Update-OrderingQ 
Add ACK to OrderingQ 

NL 

(Reformation NL 

SV 

Update-OrderingQ 
Update RecVote 
Add ACK to OrderingQ 

NL 

Reformation NL 

NIR 

Updat e-Or deringQ 
Update RecVote 
(none) 

NL 

(site in list 
Reformation NL 

NIR 

Unicast RecACKNL to 

NL 

List is invalid 
Reformation NL 

ACKNL 

Reform Site 
Commit NL 

Unicast RecACKNL to 

RecStart 

List is valid 
correct Info 

SV 

Reform Site 
Unicast RecVote to 

RecStart 

incorrect Info 

AR 

Reform Site 
Multicast RecAbort 

Failure 

packet is RecVote 

AR 

Multicast RecAbort 

RecAbort 

correct Info 

AR 

(none) 


NOTE: Each time a Slave Site receives a RecStart from the Reform 
Site, the Slave Site is to restart its retransmission schedule for 
its RecVote. This is needed so that updates to the MaxTSP and 
SynchTSP of the reformation do not cause a Slave Site to prematurely 
initiate abortion of a reformation. Every time a Slave Site updates 
it RecVote, the site must also restart its retransmit schedule on the 
RecVote packet. A Reformation NL is a New List that meets the follow- 
ing critieria: (1) Version number is correct with current Reforma- 
tion, (2) The current Token Site and the next Token Site are the 
current Reform Site, (3) The Timestamp of the NL must be in the range 
SynchTSP+1 to MaxTSP+1 of the current Reformation, (4) The operation 
type of the NL must be a reformation operation, and (5) The new TRID 
of the NL must be equal to the TRID of the reformation. 

It is practically impossible at this step of reformation to tell the 
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difference between a viable reformation NL and an incorrect one. 
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ACK New List State Table (current state is ACKNL) . Events not men- 
tioned have no action and cause no transition. The sequence of 
actions are executed before the conditions are checked. 


Event Condition ( s ) 

Next 

State 

Action (s) 

Data 

(none) 

ACKNL 

place packet in DataQ 

NMD 

(none) 

ACKNL 

Updat e-Order ingQ 
place packet in DataQ 

LCR 

(none) 

ACKNL 

Updat e-Order ingQ 
place packet in DataQ 

NL 

Timestamp < 

ACKNL 

Updat e-OrderingQ 
Add NL to OrderingQ 

NL 

Reformation NL 
Reformation NL 

ACKNL 

Updat e-Order ingQ 
Unicast RecACKNL to 

NL 

! Reformation NL 

AR 

Reform Site 
Multicast RecAbort 

NL 

incorrect Info 
! Reformation NL 

NTS 

Add Reformation NL 

NL 

Timestamp > 
Reformation NL 
'.named Token Site 

[Reformation NL 

PT 

to OrderingQ 
Commit Reformation NL 
Add NL to OrderingQ 
Updat e-Order ingQ 
Add Reformation NL 

NL 

Timestamp > 
Reformation NL 
named Token Site 
OrderingQ consistent 
Token passed 
[Reformation NL 

TS 

to OrderingQ 

Commit Reformation NL 

Add NL to OrderingQ 

Update-Order ingQ 

Pass-Token 

Add Reformation NL 

NL 

Timestamp > 
Reformation NL 
named Token Site 
OrderingQ consistent 
'.Token passed 
[Reformation NL 

GP 

to OrderingQ 

Commit Reformation NL 

Add NL to OrderingQ 

Update-Order ingQ 

Pass-Token 

Add Reformation NL 

ACK 

Timestamp > 
Reformation NL 
named Token Site 
[OrderingQ consistent 
Timestamp < 

ACKNL 

to OrderingQ 
Commit Reformation NL 
Add NL to OrderingQ 
Updat e-Order ingQ 
Add ACK to OrderingQ 

ACK 

Reformation NL 
Timestamp > 

NTS 

Updat e-OrderingQ 
Add Reformation NL 

ACK 

Reformation NL 
[named Token Site 

Timestamp > 

PT 

to OrderingQ 
Commit Reformation NL 
Add ACK to OrderingQ 
Updat e-Order ingQ 
Add Reformation NL 
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ACK 

Reformation NL 
named Token Site 
OrderingQ consistent 
Token passed 

Timestamp > 

TS 

to OrderingQ 

Commit Reformation NL 

Add ACK to OrderingQ 

Update-Order ingQ 

Pass-Token 

Add Reformation NL 

ACK 

Reformation NL 
named Token Site 
OrderingQ consistent 
! Token passed 

Timestamp > 

GP 

to OrderingQ 

Commit Reformation NL 

Add ACK to OrderingQ 

Update-OrderingQ 

Pass-Token 

Add Reformation NL 

Failure 

Reformation NL 
named Token Site 
! OrderingQ consistent 

packet is RecACKNL 

AR 

to OrderingQ 
Commit Reformation NL 
Add ACK to OrderingQ 
Update-OrderingQ 
Multicast RecAbort 

RecAbort 

correct Info 

AR 

(none) 

RecStart 

incorrect Info 

AR 

Multicast RecAbort 


NOTE: 
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Abort Recovery State Table (current state is AR) . Events not men- 
tioned have no action and cause no transition. The sequence of 
actions are executed before the conditions are checked. 


Event 

Condition (s) 

Next 

State 

Action (s) 

Data 

(none) 

AR 

place packet in DataQ 

NMD 

(none) 

AR 

Updat e-Order ingQ 
place packet in DataQ 

LCR 

(none) 

AR 

Updat e-Order ingQ 
place packet in DataQ 

NL 

Old Version 

AR 

Updat e-OrderingQ 
Add NL to OrderingQ 

NL 

Reformation NL 

AR 

Updat e-Order ingQ 
Multicast RecAbort 

ACK 

Version is of 
last attempt 
(none) 

AR 

Add ACK to OrderingQ 

RTA 

(none) 

SR 

Updat e-Order ingQ 
Multicast RecStart 

RecStart 

correct Version 

SV 

Unicast RecVote to 

RecStart 

incorrect Version 

AR 

Reform Site 
Multicast RecAbort 

RecVote 

incorrect Version 

AR 

Multicast RecAbort 

RecACKNL 

incorrect Version 

AR 

Multicast RecAbort 


NOTE: A correct version at this stage is a version greater than the 
last known version. Fill the RecAbort packet in with data in the 
incoming packet. A NL that qualifies as a Reformation NL is any NL 
that has an operation type dealing with Reformation and has a version 
higher than the last known version. 
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